Driven by increasing usage of a variety of network applications, such as those involving the Internet, computer networks are of increasing interest. The Internet can be regarded as a collection of interconnected networks, also called autonomous systems. Autonomous systems are administrated under the same authority or under different authorities. Autonomous systems administered under the same authority are also referred to as clouds. In order to couple portions of a network together, to couple networks, or at the edge of an autonomous system, switches are often used. For example, FIG. 1 depicts a high-level block diagram of a switch 10 which can be used. This invention pertains to a switch 10 that includes a switch fabric 24 coupled with blades 7, 8 and 9. Each blade 7, 8 and 9 is generally a circuit board and includes at least a network processor 2 coupled with ports 4. The term network processor is interpreted broadly to include any packet-processing device in which packet recognition and flow control are programmable. Thus, the ports 4 are coupled with links that convey packets to or from other network nodes or hosts (not shown). The blades 7, 8 and 9 can provide traffic to the switch fabric 24 and accept traffic from the switch fabric 24. Thus, any host connected with one of the blades 7, 8 or 9 can communicate with another host connected to another blade 7, 8 or 9 or connected to the same blade. Although depicted as including network processors 2, in lieu of network processors 2, the switch 10 could include an equivalent level of programmability provided using another mechanism.
FIG. 2A depicts another simplified block diagram of the switch 10, illustrating some of the functions performed by network processors. The switch 10 couples links to other nodes or hosts (not shown) connected with ports A 12 with those links to other nodes or hosts (not shown) connected with ports B 36. The switch 10 performs various functions including classification of data packets provided to the switch 10, transmission of data packets across the switch 10 and reassembly of information into packets. These functions are provided by the classifier 18, the switch fabric 24 and the reassembler 30, respectively. The classifier 18 classifies packets which are provided to it and breaks each packet up into convenient-sized portions, which will be termed cells. The switch fabric 24 is a matrix of connections through which the cells are transmitted on their way through the switch 10. The reassembler 30 reassembles the cells into the appropriate packets. The packets can then be provided to the appropriate port of the ports B 36, and output through links to the next hop or final destination nodes or hosts. The classifier 18 may be part of one network processor 1, while the reassembler 30 may be part of another network processor 5. The portions of the network processor 1 and the network processor 5 depicted perform functions for traffic traveling from ports A 12 and to ports B 36, respectively. However, the network processors 1 and 5 also perform functions for traffic traveling from ports B 36 and to ports A 12, respectively. Thus, each network processor 1 and 5 can perform classification and reassembly functions. Furthermore, each network processor 1 and 5 can be a network processor 2 shown in FIG. 1.
Referring back to FIG. 2A, due to bottlenecks in transferring traffic across the switch 10, data packets may be required to wait prior to execution of the classification, transmission and reassembly functions. As a result, queues 16, 22, 28 and 34 may be provided. Coupled to the queues 16, 22, 28 and 34 are enqueuing mechanisms 14, 20, 26 and 32. The enqueuing mechanisms 14, 20, 26 and 32 place the packets or cells into the corresponding queues 16, 22, 28 and 34. Although the queues 16, 22, 28 and 34 are depicted separately, one of ordinary skill in the art will readily realize that some or all of the queues 16, 22, 28 and 34 may be part of the same shared physical memory resource.
Those skilled in the art will understand that such queues can represent processing bottlenecks or points of congestion. In particular, lengthy queuing delays diminish or cancel the value of packets that are eventually processed. Therefore proper operation of a network can include the purposeful and proactive discarding of some packets during instances of congestion by the enqueuing mechanisms 14 and 26.
FIG. 2B depicts further details of mechanisms in one such switch 10′. Many of the components of the switch 10′ are analogous to components of the switch 10. Such components are, therefore, labeled similarly. For example, the ports A 12′ in the switch 10′ correspond to the ports A 12 in the switch 10. In the switch 10′, the queue A 16′ and the queue A 22′ share a single memory resource 19. Similarly, the queue 28′ and the queue 34′ are part of another single memory resource 31. Thus, in the switch 10′, the queues 16′, 22′, 28′ and 34′ are logical queues partitioned from the memory resources 19 and 31.
FIG. 3 depicts various clouds 50, 52, 54, 56, 60, 62, 64, and 70 coupled via a cloud with high-bandwidth links and fast routers, typically referred to as backbone 80. Some switches 10 and/or 10′ can reside at the boundaries of the clouds 50, 52, 54, 60, 62, 64 and 70 and the backbone 80 at which connections are made. For example, the cloud 50 typically includes one or more switches 10/10′ at the connections made to clouds 52, 54, and 56. Furthermore, note that the clouds 50, 52, 54, 56, 60, 62, 64 and 70 can be viewed hierarchically depending upon their connection to the backbone 80 and the number of the remaining clouds 50, 52, 54, 56, 60, 62, 64 and 70 to which they are connected. For example, the cloud 56, which is only connected to the cloud 50, may be small and have a relatively peripheral connection to the backbone 80. The cloud 54 may be larger and higher in the hierarchy, serving as a connection point to the backbone 80 and other clouds for the clouds 50, 52, and 56.
Traffic, including data packets and administrative packets (also called control packets), traverses the clouds 50, 52, 54, 56, 60, 62, 64, and 70 and the backbone 80 at least in part by traveling through some switches 10/10′. The switches 10/10′ may provide a gateway to the Internet or other clouds 50, 52, 55, 56, 60, 62, 64, and 70. In addition, the switches 10/10′ may also be used to provide customers with different services based, for example, on the price paid by a consumer for service. A consumer may wish to pay more to ensure a faster response or to ensure that the traffic for the customer will be transmitted even when traffic for other customers is dropped due to congestion. Thus, the concept of differentiated services has been developed. Differentiated services can provide different levels of service, for different customers, or different flows of traffic through the network.
Differentiated Services (DiffServ) is an established Internet Engineering Task Force (IETF) standard for providing differentiated services (see IETF RFC 2474 and related RFCs). The DiffServ architecture recognizes the importance of clouds for providing service guarantees in the Internet and is concerned with intra-cloud service levels. Appropriate service level agreements are assumed between clouds. At the edge of a cloud, incoming traffic is mapped into a limited number of traffic behavior aggregates. A behavior aggregate flow can be viewed at each point of potential congestion as the aggregate of all traffic of the same class. A class can mean a common technical requirement, such as very low latency, a common economic value, or any combination of such concepts. Furthermore, some traffic of sufficient value can be organized in a pipeline from one edge of a cloud or combination of clouds to another edge of a cloud or combination of clouds. Potentially, one behavior aggregate flow could have its own pipeline, but in general the local confluence of all traffic in one class or behavior aggregate flow at one point of congestion determines the treatment of packets in the class without regard to details of session membership.
Thus, within each behavior aggregate flow at each point of potential congestion there could be packets from one, a few, or many sessions between individual hosts. However, DiffServ is unconcerned with session membership within a behavior aggregate flow. Instead, DiffServ is concerned with the differentiated treatment of the behavior aggregate flows inside a cloud. According to DiffServ, excess bandwidth is to be allocated fairly between behavior aggregate flows. Furthermore, DiffServ defines fairness by providing criteria for measuring the level of service provided to each behavior aggregate flow. For example, to provide differentiated services, aggregate flows could be marked “red,” “yellow,” or “green.” When insufficient bandwidth exists to support the current flows in one or more of the behavior aggregate flows, packets in pipelines marked red could be discarded to a greater degree than packets in behavior aggregate flows marked yellow. Similarly, packets in behavior aggregate flows marked yellow could be discarded to a greater degree than packets in behavior aggregate flows marked green. Thus, three levels of service could be provided.
Traffic having different levels of services may travel through the clouds 50, 52, 54, 56, 60, 62, 64, and 70. However, one of ordinary skill in the art will readily realize that the clouds 50, 52, 54, 56, 60, 62, 64, and 70 and the systems within the clouds 50, 52, 54, 56, 60, 62, 64, and 70 are vulnerable to attack. In particular, individuals can generate malicious traffic through the clouds 50, 52, 54, 56, 60, 62, 64, and 70 which would adversely affect the performance of another system within the same cloud or system(s) in other clouds. For example, an individual with connectivity to one of the clouds, such as the cloud 50, could initiate an attack, such as a denial of service (DoS) attack, on a node or nodes in another cloud such as the cloud 70. For example, system(s) in the cloud 50 could flood system(s) in the cloud 70 with administrative packets such as SYN, FIN, RST packets in the protocol TCP; any ICMP packets; or analogous administrative, control, or signaling packets in any other protocols such as in SCTP. This DoS attack could escape the notice of the administrator of the corresponding autonomous system within the cloud 50. The DoS attack could adversely affect the performance of systems within the cloud 70, result in a significant loss of resources, and require a significant investment of resources for system recovery. In addition, the administrator of the cloud 50 could be financially liable for damage done to the systems of the cloud 70. Consequently, it is desirable to manage DoS attacks to limit their adverse effects.
FIG. 4 depicts a conventional method 90 for managing DoS attacks in switches such as the switches 10/10′ and clouds such as the clouds 50, 52, 54, 56, 60, 62, 64, and 70. It is determined whether the rate at which administrative packets of a certain type traverse the switch 10/10′ exceeds a particular maximum level, via step 92. If not, then step 92 is periodically repeated. If so, then a sufficient number of administrative packets are dropped so that the traffic in administrative packets traversing the switch 10/10′ is suppressed to the maximum level, via step 94.
Although the conventional method 90 functions, one of ordinary skill in the art will readily recognize that the conventional method 90 is a rough, simplistic mechanism for managing malicious traffic through the clouds 50, 52, 54, 56, 60, 62, 64, and 70. Only a comparison of an observed rate to a maximum bandwidth indicates that any action should be taken to manage attacks. In addition, the conventional method 90 merely prevents the administrative packets from exceeding the maximum level. Thus, further improvement in the performance of the switch 10/10′ is desirable.
Accordingly, what is needed is a system and method for providing better management of denial of service attacks. The present invention addresses such a need.